-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Limit number of firewall rules per VPC #5914
Conversation
@@ -264,6 +265,20 @@ impl VpcFirewallRule { | |||
} | |||
} | |||
|
|||
const MAX_FIREWALL_RULES: usize = 32; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this an arbitrary number? Perhaps it'd be good to have a comment that explains why we chose this limit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This number feels way too low. I would expect a value in the hundreds at least, especially since we don't have tags for grouping firewall rules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, definitely. Was going to ask about the number next. How about 512?
a4b3ba0
to
75b2ea8
Compare
75b2ea8
to
a9a8755
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this PR! It'll really help set customer's expectations on what is allowed. Could you add documentation about these limits to the relevant API endpoints?
ensure_max_len(&rule.targets, "targets", MAX_FW_RULE_PARTS)?; | ||
|
||
if let Some(hosts) = rule.filters.hosts.as_ref() { | ||
ensure_max_len(&hosts, "filters.hosts", MAX_FW_RULE_PARTS)?; | ||
} | ||
if let Some(ports) = rule.filters.ports.as_ref() { | ||
ensure_max_len(&ports, "filters.ports", MAX_FW_RULE_PARTS)?; | ||
} | ||
if let Some(protocols) = rule.filters.protocols.as_ref() { | ||
ensure_max_len(&protocols, "filters.protocols", MAX_FW_RULE_PARTS)?; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If a customer is exceeding 2 or more of these limits, it'd be really nice to get a single error message that tells them every limit they've exceeded. WDYT?
Will add a line to the descriptions, and where possible add a max length to the OpenAPI schema. |
@@ -20438,7 +20439,7 @@ | |||
] | |||
}, | |||
"VpcFirewallRuleFilter": { | |||
"description": "Filter for a firewall rule. A given packet must match every field that is present for the rule to apply to it. A packet matches a field if any entry in that field matches the packet.", | |||
"description": "Filters reduce the scope of a firewall rule. Without filters, the rule applies to all packets to the targets (or from the targets, if it's an outbound rule). With multiple filters, the rule applies only to packets matching ALL filters. The maximum number of each type of filter is 256.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@karencfv I brought in something more like the console explanation here. I think it's an improvement, the only issue is that it's hard to find on the docs site, buried in the request body.
What might be nicer would be to put some basic summary of all of it here at the top... OR we could just link to the guide, which is pretty nice: https://docs.oxide.computer/guides/configuring-guest-networking#_firewall_rules
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh nice! This is great. I'd like to keep this here so the SDKs inherit the descriptions, but it would be really great to add the text from the second image as well for the docs. Would it be too weird to have it all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I’ll add more. I don’t think anyone will be mad at us for having too good of documentation.
const MAX_FW_RULES_PER_VPC: usize = 1024; | ||
|
||
/// Cap on targets and on each type of filter | ||
const MAX_FW_RULE_PARTS: usize = 256; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just occurred to me. We don't support port ranges (e.g. "3000-4000") as a value, do we? If so, we should increase this number. Or better yet, add support for port ranges at some point.
If we do support port ranges, then ignore this comment :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do support ranges. You just put in “123-456”
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sweet! Can we add that to the API docs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -20438,7 +20439,7 @@ | |||
] | |||
}, | |||
"VpcFirewallRuleFilter": { | |||
"description": "Filter for a firewall rule. A given packet must match every field that is present for the rule to apply to it. A packet matches a field if any entry in that field matches the packet.", | |||
"description": "Filters reduce the scope of a firewall rule. Without filters, the rule applies to all packets to the targets (or from the targets, if it's an outbound rule). With multiple filters, the rule applies only to packets matching ALL filters. The maximum number of each type of filter is 256.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh nice! This is great. I'd like to keep this here so the SDKs inherit the descriptions, but it would be really great to add the text from the second image as well for the docs. Would it be too weird to have it all?
I've added a nice description to the update endpoint that includes some of the explanation. Note that we need oxidecomputer/dropshot#1068 and a CSS tweak in the docs site to make this look good, but it's not awful as-is. What it will look like if we don't do anything elseWhat it will look like after we fix a couple of things in dropshot and the docs site |
Closes #5662
Closes #6032